Most processes consist of several process segments that fit together in a physically and temporally consistent manner. For example, a fluid control and imaging system, such as a urinalysis system, includes process segments for receiving a sample, aspirating the sample, and injecting the sample into a fluidics system where images are taken as the sample flows in a proper manner. To produce meaningful data, the sample receptacle, the aspirator, the valves, the pumps, and the optical components have to be in the proper positions at the proper times, and various fluids have to be released at the right time. Typically, these process segments are controlled on a real time basis by a single processor according to instructions in software or firmware. The instructions usually entail responding to various inputs by considering “hard-coded” branching conditions. This type of “hard-coded” branching takes the form of a “case statement” in which each case corresponds to a state and a relatively complicated “if” statement determines the response to inputs when in the given state.
In this type of real time operation, the process segments do not all happen completely simultaneously. For example, although the sample may be received and aspirated at the same time the flow cell is being flushed with a cleaning solution, the aspiration and the flushing take different lengths of time to complete, and therefore do not start and end at the same time. Furthermore, how long each of these processes will take to complete cannot always be predicted accurately because a process may have a random component (e.g., sample concentration will determine the time required to capture a fixed number of images) or a catastrophic unplanned event, such as the aspiration needle getting stuck or the cleansing fluid not being loaded correctly. Since the success of a process depends on each process segment running smoothly, this type of catastrophic unplanned event not only disrupts a process segment but also turns an entire process run into wasted effort if the event is not handled properly. Further, there is extra inefficiency associated with troubleshooting once it is determined that a run was erroneous because it is difficult to know exactly which process segment was in progress at a certain point in time.
In addition to the above disadvantages with a single-processor hard-coded real time controller, there is an additional source of inefficiency stemming from the need for a process engineer to collaborate with a software engineer to adjust the process parameters. While the process engineer understands the process and knows how the components ought to be set, implementation of the process usually requires a software engineer. Thus, typically, the process engineer has to explain the process and what he wants to accomplish to a programmer, who then revises the code. This process engineer—software engineer communication link not only takes time but also creates more opportunities for error based on miscommunication or misunderstanding.
For the above reasons, a method of controlling a process more efficiently is desired.